For a long time operators have used Intelligent Network (IN) based services for mobile terminals in the circuit switched domain. With the introduction of the IP Multimedia Subsystem (IMS) in the packet switched domain, operators started to deploy new services in this domain and to port existing services IN services into this domain. This provided the dilemma that two services had to be maintained. This was solved with the introduction of intermediate services in the IN domain that made use of the IMS based services, a technique generally known as “overlaying”. For this purpose the IN platform was enhanced to be capable to interface also to the packet switched domain. The enhanced IN platform is known as e.g. Multi Access Extension (MAE) server, IMS Access Adapter (IAA), or Service Domain Selection (SDS) application. The term MAE will be used in general to indicate the IN enhanced platform. This server has the capability to act towards the Mobile Switching Centre (MSC) with the IN standard CAMEL protocol and with the IMS network using the SIP protocol.
The above is valid for call control. However, also the actual media transfer (voice path, video, etc.) may need to run via the PS network. Examples are service related voice messages or the actual call is to a PS served terminal. The media transfer handling and the CS-PS conversion is handled in a Media GateWay (MGW) controlled by a Media Gateway Controller (MGC). This situation is explained in detail in FIG. 1.
The mobile station (MS) sets up a call via A by sending a Direct Transfer Application Part (DTAP) Setup message towards the MSC. The call establishment triggers the MSC to invoke an IN service, either as the called party number is a service number or the service data in the subscription of the MS contains a subscription to an originating IN service. The MSC sends via B a CAMEL Application Part—Initial Detection Point (CAP-IDP) message towards the MAE server that is received by the service S1. As S1 is an intermediate service, the actual service is in the IMS domain, the service needs to set up a SIP session towards the IMS network. Before this can be done S1 needs to take care that the voice path is routed to a MGW to allow CS to PS conversion when required. Therefore S1 sends via C a CAP Connect (CAP-CON) message back to the MSC. The CAP-CON message contains the address of the MGC to be contacted or a global address related to a group of MGCs. The MSC continues call set-up via D by means of an ISDN User Part—Initial Address Message (ISUP-IAM) to the MGC. As neither the CAP-CON nor the ISUP-IAM allow for including details required for subsequent SIP session establishment in IMS, S1 includes itself as destination in the CAP-CON message so S1 will be invoked as terminating service.
This causes the MGC to set up via E a SIP session towards S1. With the details supplied with the CAP-IDP and the internal service logic, S1 handles further the establishment of a SIP session towards S2 as originating service via F by sending a first SIP Invite message to an I-CSCF of the IMS network S2 belongs to or is associated with. During the whole duration of the call SIP messages are relayed between the I-CSCF and the MGC, and traverse the MAE server.
During SIP session set-up a route list is assembled of nodes included in the loop. After SIP session set-up al subsequent messages will follow this route. This is the reason the MAE server has to stay in the loop. Route list is to be seen here in the context of the SIP message. In case of a SIP Invite (SIP session initiating) message the nodes traversing are maintained as a chain of addresses in the VIA header field. With a response type SIP message the VIA header in reversed order is the route list followed back to the SIP invite sending node. Subsequent message follow the chain in forward or reversed order. SIP Invite has several ‘route’ header fields. Route list is used as common term for any of these ‘route’ header fields, the actual header field depending of the specific SIP message type.
The main drawback of the existing solution is that the MAE/S1 is kept occupied with SIP message relaying during the whole duration of the call while not having an added value once the call is established. This constantly ties up the resources of the MAE and in addition a full SIP protocol stack must be implemented, including all exemption handling, required for relaying all possible SIP messages. This will lead to unnecessary complexity and unnecessary system requirements for the MAE server.
The IETF RFC 3261 standard, defining the Session Initiation Protocol (SIP), has defined a protocol subset that would allow a SIP node (e.g. proxy, server) to withdraw itself from the stream during the call establishment phase. The withdrawal has to be done during the session set-up. Once a session set-up is completed a node cannot withdraw itself from the stream without terminating first the session, informing the session initiator, and setting up a new session by that session initiator.
The protocol subset is known as SIP 3XX response or SIP redirect. It entails the handing back of the SIP session establishment to a SIP session initiating node with a proposed alternative routing with a request for said SIP session initiating node to continue set-up of the session with the alternative routing. This method is however designed for SIP client to SIP server redirection and requires specific use of the Header fields in the SIP 3XX message to give alternative routing.
In the case of GSM-to-IMS overlay those same header fields do not provide the required capability for the alternative routing of the SIP session. More specifically, the header fields provide the capability to provide information needed for the alternative routing of the SIP session, but the header fields do not provide the capability to provide information needed to set data in said alternative SIP session, related to the calling party or related to the GSM network used by the calling party. Without this capability the IMS will, when receiving the alternative SIP session, perform terminating services instead of intended originating services. Furthermore SIP 3XX messages lack possibilities to include additional information to be forwarded to the IMS service like SIP Invite messages have.
Additional complicating factor is that SIP redirect is rather new and many SIP servers have not yet implemented it. The MAE, having to co-operate with a number of MGCs in the telecom network, has therefore to work with both types of SIP servers, those that know SIP 3XX and those that do not know.